In Part 1 of this four-part blog series examining wiper malware, we introduced the topic of wipers, reviewed their recent history and presented common adversary techniques that leverage wipers to destroy system data.
In Part 2, CrowdStrike’s Endpoint Protection Content Research Team discusses how threat actors have used legitimate third-party drivers to bypass the visibility and detection capabilities of security mechanisms and solutions.
For a wiper developer, there are several good reasons to switch operations into kernel space. When it comes to overwriting disks, user mode has certain limitations and is intensely monitored by AV/XDR vendors through hooking various APIs and blocking select actions. With the release of Windows Vista, Microsoft began restricting access to raw disk sectors from user mode. To bypass this, wiper developers began to drive their attack through the kernel space.
Threat actors may attempt to write their own kernel drivers, but this approach is difficult for a number of reasons. One is related to the lack of segregation between processes or drivers in Kernel space; anything can write to anywhere with no restriction. With no room for error, the machine may easily destabilize and crash. Another is that modern Windows 64-bit requires drivers to be signed by Microsoft.
Rather than writing their own kernel drivers, malware authors often resort to using drivers developed by third-party entities in order to achieve their goals. Some notable examples of wiper families that use third-party drivers include Destover, DriveSlayer, Shamoon, Dustman and ZeroCleare. Most of these leverage different versions of the ElRawDisk driver developed by Eldos, with the exception being DriveSlayer, who uses a driver developed by EaseUs.
The ElRawDisk device driver, developed by Eldos (now part of Callback Technologies), is used by several wiper families such as Destover, ZeroCleare, Dustman and Shamoon. The driver is used as a proxy to transfer actions from user mode into kernel mode and ensures that all disk operations are done on behalf of the driver, not the wiper process. This technique removes any limitations user mode processes might encounter when writing files or interacting with the disk directly. Since this is a third-party driver, the malware must implement a way to install it on the infected machine. Usually this is achieved by dropping the driver to disk and loading it via the Service Control Manager APIs, or the sc.exe tool. Legitimate drivers are also seen as “clean” by security vendors and it would not be blocked when they are installed.
ZeroCleare and Dustman use an unsigned version of ElRawDisk driver that is loaded using Turla Driver Loader (TDL). TDL installs a signed and vulnerable VBoxDrv driver. This driver is exploited to mimic the functionality of a driver loader and the unsigned ElRawDisk driver is mapped in kernel mode without having to patch Windows Driver Signature Enforcement (DSE).
After loading the driver, the wipers must grab a handle to it via CreateFile and provide a key in order to authenticate to the driver. The key is appended to the device name, and parsed out by the driver. If no valid key is supplied, the return value will be INVALID_HANDLE_VALUE. While this seems like a good idea to limit unauthorized access to the driver, in reality threat actors can reverse engineer the legitimate applications that use the ElRawDisk drivers and extract a copy of the key. Then they use that key to impersonate the legitimate tool and achieve their goals. Analyzed wipers use different keys for the ElRawDisk driver.
Figure 1. Open handle to ElRawDisk device with the serial key appended to the device name
Shamoon retrieves information about the location of the file on the raw disk by sending the FSCTL_GET_RETRIEVAL_POINTERS control code to the ElRawDisk device via the DeviceIoControl API. This information is later used to determine the raw sectors of the file that needs to be wiped.
Figure 2. Send FSCTL_GET_RETRIEVAL_POINTERS via DeviceIoControl API
Shamoon attempts to wipe the entire disk, not only the files. In order to do so, it requests partitioning information by sending the IOCTL_DISK_GET_PARTITION_INFO_EX IOCTL to the ElRawDisk driver. The partitioning information helps the wiper to determine what sectors to overwrite. To accomplish this, the wiper opens a handle to a specific partition via CreateFile and overwrites the sectors using WriteFile and SetFilePointer APIs. Shamoon writes a JPEG image to the sectors, rendering the operating system unstable and may crash at any point in time.
Figure 3. Send IOCTL_DISK_GET_PARTITION_INFO_EX via DeviceIoControl API
The code trace from Figure 4 exemplifies how wipers overwrite raw disk clusters by proxying activity via the ElRawDisk device.
Figure 4. API trace view demonstrating how the EPMNTDRV is used to wipe the disk
ZeroCleare and Dustman use the driver a bit differently than Shamoon. Once the ElRawDisk driver is loaded using TDL and a handle to the driver is obtained, it calls DeviceIoControl using one of two different IOCTLs (0x22BF84 or 0x227F80), depending on the Windows version. This call is capable of overwriting the contents of the physical drive with a message (as in Dustman wiper), or a buffer with the same byte value (as in ZeroCleare wiper).
The following figure is used in both ZeroCleare and Dustman wipers. The customdata buffer contains the data that is used to overwrite the contents of the physical drive.
Figure 5. How ZeroCleare and Dustman use the ElRawDisk to overwrite the disk with a custom buffer
As seen in the ElRawDisk driver version used by Dustman and ZeroCleare, both these two IO control codes translate to the same function call. The following snippet cannot be found in the driver used by Shamoon because it’s an older version.
Figure 6. Examples of two custom IOCTL codes from the ElRawDisk driver
EPMNTDRV is another example of a driver developed by a legitimate entity being used for malicious purposes by threat actors. This driver is developed by EaseUs for their partition manager utility. Back in March of 2022, the DriveSlayer wiper used this driver against Ukraine. It was kept inside a LZA compressed resource and loaded via the Windows Service Control Manager APIs after it was written to disk by the malware. In the following figure, we can observe the main function of the EPMNTDRV driver. It creates the device and a symbolic link followed by initialization of the DRIVER_OBJECT structure with the necessary dispatch routines.
Figure 7. Main function of the EPMNTDRV initiating various dispatch routines
Similarly to the previous driver, it allows any user-mode process to interact with the disk by proxying actions through itself. Interaction is achieved via dispatch routines like IRP_MJ_CREATE, IRP_MJ_WRITE as well as IRP_MJ_DEVICE_CONTROL. To interact with the driver, the process needs to open a handle to the device via CreateFile and provide a path like “\\.\EPMNTDRV\[value]”, where [value] represents the ID of the disk. The driver will then allow the user to operate on the “\Device\Harddisk[value]\Partition0” device through it.
Figure 8. Pseudocode view of the IRP_MJ_CREATE dispatch routine from EPMNTDRV driver, showcasing how it opens a handle to the local disk (\Device\Harddisk%u\Partition0)
In the IRP_MJ_CREATE routine of the driver, a pointer to the “\Device\Harddisk%u\Partition0” is obtained via IoGetDeviceObjectPointer and IoGetAttachedDeviceReference APIs and stored in a global variable to be later used in the other dispatch routines.
Figure 9. Pseudocode view of the IRP_MJ_WRITE dispatch routine from EPMNTDRV driver, showcasing how an IRP request is created and sent to the driver handling the HardDisk device.
The IRP_MJ_WRITE handles the write requests coming from the user mode process.and forwards them to the driver handling the disk operations. In order to achieve this, the driver makes use of the IoBuildAsynchronousFsdRequest API to construct an IRP request and sends it to the driver via the IofCallDriver API.
Figure 10. Pseudocode view of the IRP_MJ_DEVICE_CONTROL dispatch routine from EPMNTDRV driver, showcasing how IO control codes are forwarded to the HDD device driver
The the user mode process send a IOCTL to the EPMNTDRV device, the dispatch routine handling IRP_MJ_DEVICE_CONTROL requests is called and it forwards the requests to the driver handling disk operations via the IoBuildDeviceIoControlRequest and IofCallDriver APIs.
Figure 11. Pseudocode from DriveSlayer displaying how to data is sent to the third-party driver in order to overwrite the disk
Now that the EPMNTDRV driver is installed, the wiper can grab a handle to it via CreateFile and use standard WriteFile and DeviceIoControl APIs in order to send data to the driver. All requests from user mode are then forwarded to the disk driver. Now, the malware can now wipe the MBR, MFT, and files on behalf of the legitimate driver.
The CrowdStrike Falcon® platform takes a layered approach to protecting workloads, harnessing over a trillion data points analyzed daily in the CrowdStrike Security Cloud. Combining on-sensor and cloud-based machine learning, industry-leading behavioral analysis to fuel indicators of attack (IOAs) (including recently announced AI-powered IOAs ), and advanced threat intelligence the Falcon platform provides users with holistic attack surface visibility, unparalleled threat detection and continuous monitoring for any environment, reducing the time to detect and mitigate threats .
Figure 12. Falcon UI screenshot showcasing detection of DriveSlayer by the Falcon sensor. (Click to enlarge)
Figure 13. Falcon UI screenshot showcasing detection of Shamoon by the Falcon sensor. (Click to enlarge)
Multiple wiper families leverage legitimate third-party kernel drivers as proxies for running malicious activities. This provides the wipers with multiple advantages; enabling them to operate in a stealthy manner and bypassing several security products. A kernel implant provides limitless capabilities for the attacker, including easy access to the entire disk, without the operating system getting in the way. Many of the wipers we’ve analyzed use legitimate drivers to wipe raw disk sectors and, in some instances, protected files. The main weakness of this approach is that wiping raw sectors will destabilize the operating system, making it liable to crash at any moment. Crashing the OS may be in the victim’s advantage because this would halt wiping operations and potentially allow the victim to recover some of their data.
In Part 3 of this wiper series, we will discuss additional and less frequently utilized techniques implemented by various wiper families.
19dbed996b1a814658bef433bad62b03e5c59c2bf2351b793d1a5d4a5216d27e
30b3cbe8817ed75d8221059e4be35d5624bd6b5dc921d4991a7adc4c3eb5de4a
1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591
a259e9b0acf375a8bef8dbc27a8a1996ee02a56889cba07ef58c49185ab033ec
7bcd4ec18fc4a56db30e0aaebd44e2988f98f7b5d8c14f6689f650b4f11e16c0
1a09b182c63207aa6988b064ec0ee811c173724c33cf6dfe36437427a5c23446
d71cc6337efb5cbbb400d57c8fdeb48d7af12a292fa87a55e8705d18b09f516e
6709d332fbd5cde1d8e5b0373b6ff70c85fee73bd911ab3f1232bb5db9242dd4
9b0f724459637cec5e9576c8332bca16abda6ac3fbbde6f7956bc3a97a423473
fd67136d8138fb71c8e9677f75e8b02f6734d72f66b065fc609ae2b3180a1cbf
4c1dc737915d76b7ce579abddaba74ead6fdb5b519a1ea45308b8c49b950655c
c7fc1f9c2bed748b50a599ee2fa609eb7c9ddaeb9cd16633ba0d10cf66891d8a
7dad0b3b3b7dd72490d3f56f0a0b1403844bb05ce2499ef98a28684fbccc07b4
8e9681d9dbfb4c564c44e3315c8efb7f7d6919aa28fcf967750a03875e216c79
f9d94c5de86aa170384f1e2e71d95ec373536899cb7985633d3ecfdb67af0f72
4f02a9fcd2deb3936ede8ff009bd08662bdb1f365c0f4a78b3757a98c2f40400
e37bfad12d44a247ac99fdf30f5ac40a0448a097e36f3dbba532688b5678ad13
2bab3716a1f19879ca2e6d98c518debb107e0ed8e1534241f7769193807aac83
bf79622491dc5d572b4cfb7feced055120138df94ffd2b48ca629bb0a77514cc
c58940e47f74769b425de431fd74357c8de0cf9f979d82d37cdcf42fcaaeac32
44ffe353e01d6b894dc7ebe686791aa87fc9c7fd88535acc274f61c2cf74f5b8
dcbbae5a1c61dbbbb7dcd6dc5dd1eb1169f5329958d38b58c3fd9384081c9b78
Sign up now to receive the latest notifications and updates from CrowdStrike.
Detect, prevent, and respond to attacks— even malware-free intrusions—at any stage, with next-generation endpoint protection.